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The RICIS Concept 


The University of Houston-Clear Lake established the Research Institute for 
Computing and Information Systems (RICIS) in 1986 to encourage the NASA 
Johnson Space Center (JSC) and local industry to actively support research 
in the computing and information sciences. As part of this endeavor, UHCL 
proposed a partnership with JSC to jointly define and manage an integrated 
program of research in advanced data processing technology needed for JSC’s 
main missions, including administrative, engineering and science responsi- 
bilities. JSC agreed and entered into a continuing cooperative agreement 
with UHCL beginning in May 1986, to jointly plan and execute such research 
through RICIS. Additionally, under Cooperative Agreement NCC 9-16, 
computing and educational facilities are shared by the two institutions to 
conduct the research. 

The UHCL/R1CIS mission is to conduct, coordinate, and disseminate research 
and professional level education in computing and information systems to 
serve the needs of the government, industry, community and academia. 
RICIS combines resources of UHCL and its gateway affiliates to research and 
develop materials, prototypes and publications on topics of mutual interest 
to its sponsors and researchers. Within UHCL, the mission is being 
implemented through interdisciplinary involvement of faculty and students 
from each of the four schools: Business and Public Administration, Educa- 
tion, Human Sciences and Humanities, and Natural and Applied Sciences. 
RICIS also collaborates with industry in a companion program. This program 
is focused on serving the research and advanced development needs of 
industry. 

Moreover, UHCL established relationships with other universities and re- 
search organizations, having common research interests, to provide addi- 
tional sources of expertise to conduct needed research. For example, UHCL 
has entered into a special partnership with Texas A&M University to help 
oversee RICIS research and education programs, while other research 
organizations are involved via the “gateway" concept 

A major role of RICIS then is to find the best match of sponsors, researchers 
and research objectives to advance knowledge in the computing and informa- 
tion sciences. RICIS, working Jointly with its sponsors, advises on research 
needs, recommends principals for conducting the research, provides tech- 
nical and administrative support to coordinate the research and integrates 
technical results into the goads of UHCL. NASA/JSC and industry. 
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Preface 


This RICIS document is one of a series of technical articles addressing different subjects 
associated with computing and information systems. The various articles range from 
those that have been directly stimulated by specific RICIS activities to those that discuss 
issues of immediate or longer term concerns of the overall RICIS program. The articles 
reflect the ideas, thoughts and findings of their respective authors and do not necessarily 
represent those of any specific organization. The articles in this series have not generally 
been subjected to any organized review process. However, some articles of the series will 
be submitted for publication in specific professional journals. 
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Introduction 


As societies move further into an “information age,” as more people become computer 
literate and more of us become dependent on computing and information systems, greater 
concern is necessarily being given to critical complex issues associated with this evolving 
technology. While over the last four decades we have witnessed tremendous advance- 
ments in computer hardware technologies, we are increasingly experiencing the adverse 
effects of critical deficiencies in our abilities to develop the software needed to harness the 
generic capabilities of our hardware technology. 

In the computer journals and tabloids, there have been a plethora of articles written 
about the software engineering field. But while advocates of the need for an engineering 
approach to software development, we are at once impressed with how many authors 
have treated the subject of software engineering without adequately addressing the funda- 
mentals of what engineering as a discipline consists of. In addition, there is an absence 
of a sufficient address of the role of the supporting sciences to engineering in the context 
of the relative roles of computing science and software engineering. The purpose of this 
article is to set forth some arguments as our attempt to NOT once more prove that Lord 
Acton was correct when he wrote, “What we learn from history is that we do not learn 
from history.” In this treatise, we have attempted to bring together a discussion of the 
various related facets of this issue in a logical framework to advance the thesis that the 
software development process is necessarily an engineering process and that we need 
formally educated software engineers to develop our complex software systems of the 
future. 

The purpose of this paper, then, is to examine MORE OF THE DETAILS OF the issue of. 
“whether or not the design and development of software for digital computer processing 
systems should be both viewed and treated as a legitimate field of professional engineer- 
ing.” In addition, we examine the type of academic and professional level education pro- 
grams that would be required to support a “software-engineering" discipline. Lastly, we 
comment on the future role and importance of “computer science" in the support of “soft- 
ware engineering.” 
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Background 


It is prudent to recall the dangers of what the conventional wisdom portrays as the fea- 
tures of engineering disciplines. It has often been said that engineering is more of an art 
than it is a science. An art may make use of the findings of a science, but it presumably 
does rjot advance the knowledge base of the science itself. Others have commented on 
the “cookbook recipe” approaches of some decades earlier engineering practitioners. 

These were included in the common views of the conventional engineering disciplines 
prior to World War n when, coincidentally, major changes in technology were still rela- 
tively slow paced. This all began to change in the 1940’s with the stimulus provided by 
World War II. There is an interesting anecdote about Dean Terman’s stint as a founder of 
the Lincoln Laboratories which was credited with developing advanced and somewhat 
novel concepts in radar during and after World War II. When Dr. Terman first sought to 
get technical personnel to Lincoln Laboratories, he brought in engineers. They were to 
develop new experimental equipment to implement the concept of radio ranging. Much to 
Terman’s dismay, he observed that most of his engineers seemed to lack adequate back- 
grounds to develop the new innovative designs required, but tended to only know how to 
design and build equipment which was quite similar to that built before. He observed 
that physicists on the project were generally better able to do the innovative design work 
that he thought of as “engineering" work. This and similar experiences of others during 
this era later had a profound effect upon the thrust of engineering education. In particu- 
lar, electrical engineering experienced a most profound revision as a result of the “explo- 
sion” of new and advancing technologies after WWII. David Pames, an electrical engineer, 
commented on Dijkstra’s work, “On the Cruelty of Really Teaching Computing Science" 
that “My own engineering education included more courses in the Mathematics Depart- 
ment (taken side-by-side with mathematics students) than courses offered by the Electri- 
cal Engineering Department." [1]. What he has eloquently established is the “new” (and 
perhaps over-reactive) philosophy engendered by Dr. Terman’s experiences: as we have 
moved into a fast changing, high technology culture, it is no longer sufficient for an engi- 
neer to be capable of doing what has been done before. They need to be well-versed in 
fundamentals of the theories derived from the supporting sciences, be well versed in the 
appropriate mathematics and be capable of extending the derivation of the principals and 
formulae to apply to new situations. “Recipe engineering" proved not to provide sufficient 
flexibility, especially in an age of fast changing technology such as we are experiencing in 
the computer field. 


What is the Conventional Wisdom? 

or 

(Are We Well Served by the Conventional Wisdom?) 

With the emergence of the recognition of the need to treat the software development pro- 
cess as an engineering process and with the advent of the emergence of the first software 
engineering curriculum, we are seeing some similarities to the past. 
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In 1989, an article relating to software engineering curriculum quoted a Taxonomy of 
Educational Objectives. This taxonomy related that students of software engineering 
need knowledge of computer methods, classification and abstractions but not any deep 
understanding of them. [2], We think this oversimplifies the problem and breadth with- 
out depth is not enough. 

Just as the first electrical engineering curriculum evolved from physics, we see the soft- 
ware engineering curriculum evolving primarily from that of computer science and to a 
lesser extent from electrical engineering. The conventional wisdom of software engineer- 
ing, therefore, has a tendency to be biased more by the tenets of science and mathematics 
and, in particular, those of computer science than by those of engineering. There is a 
question however about computer science as it is currently studied, as we shall see. 

It is our belief that software engineering practices and supporting educational curriculum 
can benefit from drawing more heavily on the conventional wisdom of modem day engi- 
neering. This approach calls for a clear understanding of the important complementary 
differences between engineering and science. It is also beneficial to keep in mind that the 
transition of a “practitioner” from science to engineering and vice versa is not usually a 
trivial one. The practice of a disciplined engineering approach to the design of a new or 
better product is quite different from the scientific practice of defining a research experi- 
ment to discern new knowledge. To compound the difficulty, a difference in the tempera- 
ment and motivations of engineers and scientists also often exists. In making a leap to 
engineering, it is critical to keep in mind that engineering is a “design discipline." As 
such, engineering design methodologies are the heart of engineering. While their applica- 
tion can benefit from “tools," without well understood design methodologies, tools are 
fairly useless. 

Due to the early history of software development practices, conventional wisdom has a 
tendency to view software engineering as programming and that at most a proper set of 
tools and appropriate management practices are sufficient to overcome the critical issues 
of complex software development. 

In addition to overcoming such common wisdom views as these, we have considerable 
evidence that software engineering and its associated methodologies and technologies are 
going to be as fast changing as those we have experienced in other engineering fields over 
the past 50 years. This indicates that software engineers are going to need a rich back- 
ground in a variety of supporting subjects if they are to be able to stay current in the 
field. This will be true for both those who engineer future “systems” software as well as 
the developers of “applications” software. 


1$ Software Engineering an Engineering Discipline? 

What we seek to show is not that software engineering is a “Doomed Discipline," a view 
espoused by Dr. Dijkstra, but that it needs to address the subjects of computer science 
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and engineering from a formal methods point of view as well as a so-called practical view- 
point. Mathematical modeling is as essential to the software development process as it is 
to other engineering fields. It is also not desirable for software engineers to continue to 
design software that requires all of its parts to be newly created in order to Implement the 
design. The use of properly designed and verified (i.e. engineered) “component parts" in 
software engineering is as critical to the success of future software development projects 
as it is in other engineering disciplines. Just as in conventional engineering, the software 
designer needs to design to take advantage of existing proven component parts wherever 
possible. We believe that it is at least now clear that the products of software engineering, 
e.g. design specifications, software system designs, attendant coded implementation pack- 
ages, testing, etc. are, in fact, representative of the products of engineering. The resulting 
stored instructions in a computer system’s hardware memory elements are just as real as 
the “electrical components” that do the work of the design in any electronic system. 

Science and engineering are different disciplines (professional fields of endeavor) that are, 
nevertheless, significantly related and mutually supporting of one another. In a funda- 
mental way, science supports engineering since the utilization of the scientific theory 
provides the foundations of the engineering disciplines. It is interesting to note that engi- 
neering also supports science in that the engineering of scientific instruments, compo- 
nents and materials, etc. is critical to advanced research in the sciences (physics, chemis- 
try, etc.). Clearly during the course of one’s profession, it is not unusual for scientists to 
engage in engineering activities and conversely for engineers to engage in science. How- 
ever, these two endeavors are significantly different and should be recognized as such. 


What is Science? 

The quantitative sciences of physics, chemistry, meteorology, astronomy, as well as certain 
sub-fields of geology and biology are now generally viewed as separate scientific disciplines 
which have somewhat fuzzy (difficult-to-define) boundaries. The sharp lines of demarca- 
tion of these fields have become less rigid as fundamental unifying principles have been 
discovered which tend to unite them. An example is the underlying discoveries of atomic 
physics which have had a profound effect upon the concepts of chemical bonding. The 
boundaries between chemists and physicists are often blurred. 

Scientists are the professional practitioners who are educated and trained in the use of so 
called “scientific methods" to produce new knowledge in the various fields of science. This 
ever advancing knowledge is comprised of collections of facts, classes of models and gener- 
alizations thereof which systematize and correlate observed facts to support predictions of 
phenomena that can be compared with later observations or experimental results. 

Scientific theory is in a nearly continuous state of advancement. Historically, we have 
seen nearly all the once accepted scientific conceptual schemes of the past disproved by 
increasingly innovative experimental and observational techniques and replaced by either 
modified or new theories. 
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What i$ Engineering? 


Engineering is the practice of applying the existing bodies of scientific knowledge to de- 
velop new capabilities or to develop more cost-effective and/or reliable products and 
services to improve already existing facilities or to generate new ones. Engineering com- 
bines the use of knowledge together with the “art" and know-how which has been built up 
and passed along over time by the body of practicing professionals. 

This is not to say that engineers do not require the analytical ability possessed by scien- 
tists. There is no way that an engineer could have developed the technology which has 
played a major role in the advancement of science without having an appreciation of the 
phenomena that technology was to observe. A clear understanding of underlying theory 
is critical to its application in engineering. Engineering may be viewed as similar to the 
applied sciences, in the same way, that the practice of medicine is applied biological 
science. Physicians must understand and appreciate the biological findings before they 
can apply them intelligently. 


So What is the Difference? 

The approaches of science, the so-called scientific methods, are substantially different 
from the more commonly practiced approaches of engineering. Scientific methods all 
start with a collection of facts, followed in turn by considerable thought, speculation and 
conjecture. The result is the development of alternative working hypotheses that can be 
tested and evaluated. Hopefully, these hypotheses lead to generalizations of predictive 
theory. 

A well understood example of this process is the historical sequence leading to the devel- 
opment of Newton’s Second Law. The astronomical observations of Tycho Brahe were 
followed in turn by the development of Kepler’s Laws which captured the relationships 
among Brahe’s facts. Then, the generalizations of Newton’s Principles culminated the 
process with their inherent broader capability of prediction. 

On the other hand, engineers are practitioners who are educated and trained principally 
in the comprehension and use of knowledge, empirical evidence, and more importantly, 
disciplined problem solving methods to achieve solutions to technical problems and pro- 
duce new and/or improved capabilities. Commonly accepted engineering approaches 
generally begin with the identification of the need for a new or improved capability and 
this is often described in terms of requirements. These are in turn translated into specific 
product or system specifications. Analytical and physical modeling techniques are used 
to analyze and develop a design. A resulting design, to be useful, must be such that it 
can be implemented with existing materials and processes or alternatively with materials 
or processes that can be developed. In the next step, the design is fabricated and tested 
to determine how well it meets the initially determined requirements of the design and 
implementation specifications. An economic or “business” decision may then be made as 
to the viability of the product. If it is found to be useful and cost effective it is then fur- 
ther engineered for manufacture. 
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An example of this process Is the development of the diesel engine by Rudolf Diesel. He 
had hoped to design and develop an internal combustion engine which approximated the 
ideal thermodynamic Carnot cycle. When the prototype design literally blew up during 
test, he redesigned the engine to use a less efficient but more practical cycle for which 
materials and fabrication practice were available. The ideal cycle performance require- 
ments were relaxed and the rest is history. 


So What is Computer Science? 

(As We Know It Today) 

With the general definitions thus delineated, it is clear that some practitioners of com- 
puter science already are practicing some sort of engineering or at least applied software 
science. Not all computer scientists are searching for new algorithmic knowledge con- 
tinually. Many computer scientists are developing software systems to accomplish spe- 
cific purposes. Is not the design of a data base system an application of software design 
and development? 


What Does Electrical Engineering Have To Do With It? 

(With Software Engineering, Of Course) 

Electrical engineering is that branch of engineering primarily responsible for designing 
and developing the hardware portions of computing and information system products and 
systems. The sub- field of computer engineering has been established under electrical 
engineering just as those of power, communications, radio, television etc. 

It is interesting to note that the field of electrical engineering is some 150 years old and 
was initially established on the basis of the needs and opportunities suggested by the 
theories of the physicists and mathematicians of that time. The first “electrical engineers” 
were physicists who became personally interested in going “outside” the sciences to de- 
sign and build the first products promised by the newly found scientific theory. Over 150 
years, the discipline of electrical engineering has gone through a metamorphosis and 
become formalized and marked by the use of “engineering approaches.” The first curricu- 
lum in electrical engineering in the U.S. appeared in the early 1880’s. Today, electrical 
engineers are educated within accredited university schools of engineering and enter the 
work-place in a continuing process. 

The specialties in computing hardware systems arose in electrical engineering during the 
1960’s. One of the major outcomes of their engineering progress was the development of 
general purpose digital computing systems having a generic capability to handle and 
compute with data. This concept of “general purpose" required that these generic sys- 
tems be “programmed” to accomplish the varied specific purposes desired. These pro- 
grams became known as “software” and the practitioners who developed these programs 
came to be called “programmers.” Programmers came from many different fields and had 
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widely differing backgrounds. Initially, programming was primarily an art and program 
development methods were, for the most part, left as an individualistic practice. This 
“artisan” approach was reasonably satisfactory until the late 1960’s when software appli- 
cations and systems began to become increasingly complex. 


Lo the Computer Scientist! 

In the 1960’s, the first departments of computer science were established in academia. 
Initially, these concentrated on mathematical techniques necessary for numerical analysis. 
The development of non-numerical programming algorithms and theory and the develop- 
ment of “higher level” computer languages followed. 

By the late 1960’s, electrical and other engineers were producing computer hardware 
systems of considerable capabilities. More importantly, there was the promise of new 
systems having much improved capabilities with significantly reduced costs in the near 
future. Computer engineering had been bom as a viable branch of electrical engineering. 
However, the state of the software was not keeping pace with the hardware. 

Computing science departments became the primary source of people, who went into the 
“programming field" and were the professionals faced with solving the so called “software-' 
crisis” as the software problem was first termed in the late 1960’s. 


The Software Engineer Cometh! 

During the late 1960’s, the idea of the need to “engineer” software developed and matured. 
First, the special purpose digital computer and then the general purpose computer showed 
that software systems could indeed replace some special purpose hardware. A program- 
mable machine could perform the function of a hard-wired circuit. An early example of 
this was the implementation of a phased lock loop for an aircraft tracking system through 
use of a software program running on a PDP- 1 1 digital computer. This type of implemen- 
tation punctuated the dissolution of the lines of demarcation between electrical engineer- 
ing and computer science. 

During the period of the 1970’s and certainly by the mid 1980’s, the idea and various 
descriptions of a “discipline of software engineering” were advanced. By the end of the 
1980’s, academia had produced the first academic programs of software engineering at the 
masters level. 

Software engineering is the missing branch of engineering needed to design and develop 
the software systems required to run the hardware products and systems. In a sense, 
software engineering is to what is conventionally called computer science as production 
engineering is to design engineering. (In a very real sense in the future, software engineer- 
ing needs to be to computer science what electrical engineering has been to physics). 
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The basic aspects of software engineering which need to be understood are: [5] 

• Technical, 

• Managerial, 

• Legal, 

• Security. 

The technical aspect includes methods and tools for: 

• Deriving system(product) specifications. 

• Designing products and systems, 

• Building or implementing designs, 

• Testing (verification and validation) of products and systems, 

• Specifying the operation and maintenance of these products and systems. 

The legal aspect includes: 

• Basic legal considerations which are needed to survive in business and protect 
product rights. 

• Specific processes associated with conducting a business including: 

Software program protection (patents, copyrights, trade secrets). 

Contract law. 

Negotiations, 

Tax considerations. 

Labor law, 

Warranty of software performance. 

Ethics. 

The security aspect includes: 

• Concepts, the theory of and need for security in differing software systems, 

• Tools for generating secure software. 

• Questions of individual privacy and methods of preventing the compromise 
thereof. 

• Methods for measuring system security. 

The management aspect includes: 

• The need for a thorough insight into those basic environmental elements that a 
manager must control to attain smooth, effective and efficient product develop- 
ment which will have desirable operational and user interface characteristics over 
the product life cycle. 
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• Management tools and techniques of importance in the design, development and 
sustaining engineering of products. 

What About the Curriculum Requirements? 

The engineering qualities of importance to a software engineer which need to be ad- 
dressed in any educational program fall into three main categories; viz. basic knowledge, 
skills and attitude: 

• Basic knowledge comprised of fundamental and applied science, 

• Fundamental knowledge of physics, chemistry and mathematics whichprovide 
the foundation upon which all knowledge is assembled, 

• Applied sciences knowledge consisting of computer software and hardware 
basics and practical network theory and including knowledge of other engineer- 
ing disciplines such as practical thermo dynamics which bridge the gap between 
the knowledge base and engineering design, 

• Basic skills such as good communication, judgement skills, logical and orderly •* 
decision processes, good analytical capabilities and a concept of teamwork. 

• Attitude, which is hard to teach but is necessary for effective engineering 
reflects a curiosity, a questioning attitude, objectiveness and reasonableness. 

The general steps of the engineering method must not be overlooked. The principal steps 
are: 

• Problem formulation, 

• Problem analysis, 

• Search for alternative solutions, 

• Decision, 

• Specification preparation, 

• Implementation, 

• Test and evaluation. 


What Are the Objectives of Modem Engineering? 

Whereas the objectives of science are to discover and create “knowledge,” the objectives of 
engineering are to create new and improved capabilities which support man in his en- 
deavors. Therefore, while engineers need to be well versed in the underlying sciences, 
they need to be in the resulting techniques of engineering analysis for a variety of physical 
phenomena. Only in this way, can an engineer hope to create related new and improved 
products. 
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What Then Should Be the Future Objectives of Computer Science? 


Freed of the pressure to produce computer scientists capable of serving as “engineers," 
the computer science community can. in the future, focus upon creating the body of 
fundamental, theoretical, scientific and mathematical material upon which advances in 
software engineering can be solidly built! We assert that such a knowledge is critical to 
important advancements in future software design processes and to the development of 
an engineering capability to verify important characteristics of a proposed design or to 
determine the trade-offs among alternative designs. Such a capability is essential for 
achieving and maintaining the reliability and correctness of a design, which other engi- 
neering disciplines provide their clients and to which society has come to demand. No 
longer do engineers build structures on the basis of rough “sketches” and then have to 
resort to testing to discover fundamental design flaws followed by major and empirical re- 
construction. Important work by computer scientists is needed to advance the concepts 
of and to provide the underpinnings of “provable software design." Other advances are 
needed to support better simulation methods especially for real-time systems simulation, 
faster artificial intelligence systems and expert systems. Indeed, some of these advance- 
ments may be closely linked to developments in the science of parallel processing. 


How Can These Objectives Be Attained? 

An engineering curriculum must expose the student to a wide cross section of different 
fields while providing specialized training in a particular engineering specialty. As an 
example, consider that an electrical engineering student takes courses in a variety of 
sciences (physics, chemistry, mathematics, etc.) as well as from the various classical 
engineering disciplines (mechanical, civil, chemical, etc.). In addition, there are special- 
ized courses in the electrical engineering field (communications, control, power, electron- 
ics, etc.). 

The standard undergraduate engineering curriculum is now usually regarded as a five- 
year program providing this broad background in engineering and fundamental support- 
ing sciences. Many of these programs approximate or exceed 160 credit hours. Graduate 
degree programs lead to a more in-depth education in a selected area within a particular 
engineering field. 

Software engineering appears to be generically similar to other engineering fields in that it 
builds upon the knowledge of supporting sciences. It is involved with engineering new 
capabilities stemming from the development of computer software products and systems. 
The engineering of these new systems is also predicated upon a number of related engi- 
neering disciplines depending upon the nature of a particular specialty. For example, the 
engineering of a software system which implements a complicated automatic control 
system. Thus a software engineer, who plans to develop large control systems, needs to 
understand the mathematics of control and the physics of the so-called “plant" which is 
controlled. 
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So Where Are We Now? 


The state of development of the field of computer engineering at this time may be com- 
pared to the states of already existing engineering disciplines at the time of their emer- 
gence. In the absence of academic and/or professional educational programs the early 
practioners of an engineering field came from a variety of related fields with considerably 
different specialized training. 

The first practitioners of electrical engineering, some 150 years ago, were physicists, chem- 
ists and others with little formal education in any engineering methodology and only the 
practical experience of their laboratory work. In addition, few if any standards existed to 
guide engineering development. During this period of transition, much was done in an ad 
hoc fashion. While the other engineering fields each followed a somewhat different devel- 
opment course, in detail, their development followed a similar pattern. Early “trial and 
error approaches” followed by less qualified practitioners resulted in designs which were 
inadequate from the viewpoints of reliability, cost and often safety. In each field, profes- 
sional approaches based upon good engineering practices and the educational study 
necessary for them were gradually adopted. It was only at that point of advancement that 
“costly mistakes” could be avoided by early detection through “modeling” and “engineering 
analysis.” Baber [3] makes an interesting precautionary point: software engineering must 
imply an approach to this vocation which would be recognized by other engineering profes- 
sions as having the basic characteristics typical of those other (conventional) fields. Sys- 
tematizing work, tools and the application of management principles to the organization of 
work, useful as they may be, are not the essence of engineering and are not sufficient to 
transform our occupation into a professional engineering field. 

By comparison in most all of the curricula in software engineering we have reviewed, the 
broad background necessary for the practice of engineering is absent. What most seem to 
do is to structure courses in specification writing, production management and testing of 
large software systems regardless of nature of the system itself. With this direction, it 
would seem that the source of students for the master of software engineering should 
come from technical areas other than computer science but with perhaps a minor in 
computer studies. 

So What Should We Do? 

It is our hypothesis that the software engineering discipline is a new engineering field in 
the early stages of transition from science and practice to a professional engineering disci- 
pline. To make it viable there should be care in selecting applicants with the appropriate 
background which will lend itself to complement the training which the current software 
engineering curriculum can offer. The structure of the curriculum must contain the 
fundamentals of computer science Just as the other engineering curricula contain physics 
and chemistry. In addition, the principles of software system design must be studied with 
the appropriate laboratories included. As a by-product of this, “computer scientists” will 
be freed to do the important work of extending the knowledge base that is critical to impor- 
tant advancements in the field of software engineering. 
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Summary and Conclusions 


If software engineering is to become an accredited and operative field of engineering, then 
a first step is for schools of engineering to commit to the development of an undergradu- 
ate curriculum that provides for a background in the standard natural and applied sci- 
ences. in mathematics and associated computer science. Importantly, the undergraduate 
curriculum needs to provide the standard cross-section of introductory course work 
common to all undergraduate engineering programs. 

This would include the standard and much needed background in mechanics, strength of 
materials, fluid flow, thermodynamics, electrical and electronic systems. In addition, 
software engineers would benefit from introductory courses in business and management. 
Such a program would provide software engineers with an exposure to business applica- 
tions that would prove useful in the engineering of “management information systems." 
Courses in technical writing, economics, engineering law and ethics would be candidates 
to round out the engineering background of the undergraduate software engineering 
program. 

Secondly, engineering schools need to develop masters level programs that allow excur- 
sions of considerably more depth in specific specialty areas such as operating systems 
modeling, simulation, networks and distributed systems, system optimization and soft- 
ware design methodologies. In addition, the master's level would have a core which in- 
cludes at least one course in advanced linear systems. 

Lastly, doctoral programs need to be derived to produce individuals with backgrounds 
suitable to participate and lead needed engineering research in the important frontiers of 
future software engineering topics. Again, this can be observed to have been critical to 
the development of the already established, mature engineering disciplines. Clearly, 
software engineering researchers are going to be critical to the development of engineering 
methodologies required to design ever increasingly complex, sophisticated, reliable and 
cost effective systems of the future. 

The current trend appears to have the first software engineering programs appearing at 
the master’s level. Often students are not required to have an undergraduate engineering 
degree and often have not had an introduction to even generic engineering goals, meth- 
ods, ideologies, etc. These master's level programs often take on more the form of ad- 
vanced computer science than advanced engineering. It is the authors' contention that 
until academic institutions develop more suitable “full-range" educational opportunities in 
software engineering, students will continue to come out of our colleges and universities 
with educational backgrounds not forged to serve them well. "Full-range" educational 
programs in software engineering and computer science will enhance both the practice of 
computer science, that is successfully advancing the state of underlying knowledge and 
theory needed, and the application of common engineering practices in the design and 
development of the complex software systems required by current and future applica- 
tions. 
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The authors would point to the field of chemistiy as a good example where precedence for 
success has already been established. Chemical scientists and chemical engineers with 
their different academic training are equipped to advance the theory as well as practices 
to produce solutions to complex chemical applications. 

It is the authors opinion that rather than some type of crisis, we have a well defined and 
continuing need for software engineering professionals to complement the pursuits of our 
computer scientists and computer (electrical hardware) engineers through the engineering 
of the “heart” of future computer and information systems. We cannot afford placing the 
responsibility for the design of safety and mission critical systems to unqualified and 
improperly educated personnel. Cases like the Theric 25 radiation disaster caused by a 
software malfunction can be avoided by proper Software Engineering. (7] 
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